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FIELD OF THE INVENTlbN 

The invention applies to digital networks, especially when they are 
dynamical, evolutive, heterogeneous, and when they contain wireless parts. 



5 BACKGROUND ART 

Definitions: 

A network is dynamic when devices can move, be on / off, be 
reachable or not. 

A network is evolutive when new devices may join the network, older 
1 0 devices may definitively disappear from the network or be stolen. 

A network is heterogeneous when not all devices are able to 
communicate by pairs. 

A community is a network composed of devices under the 
responsibility of a main user. The main user is either a single user or a specific 
15 user within a group of persons. Only the main user is able to authenticate 
against community devices in order to perform the validation operation required 
by the system. 

The frontier of a community is defined following its characteristic 

properties: 

20 - Any device in the community can verify that it belongs to the 

community. 

- Any device in the community, can verify whether any another 
device also belongs tb the community or does not belong to the 
community. 

25 - Only the main user 1 can perform frontier operations such as 

inserting or removing devices from the community. 

Prior art 

Most prior art comes out from the field of Company Wide Digital 
30 Networks, Ad-Hoc Networks (i.e. networks with no pre-existing infrastructure, 
generally build for the specific use of a group of person - Ad-hoc network 
duration does not exceed group duration), Digital Home Networks, Wireless and 
Mobile Networking. 

The first communities corresponded to a basic model: the community 
35 frontier were identical to network frontier. If a device was reachable through the 
network, then it was a member of the community. Conversely, any device that 
was not reachable through the network was not a member of the community. 
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Such communities exactly correspond to isolated Local Area 
Networks (LAN) as they were used in companies, before the need to connect 
un-trusted networks (such as the Internet). 

In these communities, the security of the frontier relies on two main 

5 factors: 

- Only authorized users are able to use a device and the network. | 

- No un-trusted device can be inserted on the network. 

Both factors were enforced by the role of a main user (called a 
network administrator) and the location of devices and network In a secure 
10 place. 

These communities are not adapted in cases where the network is 
mobife or needs to cross un-trusted devices. Administrative tasks are also very 
demanding, and generally not accessible to a typical domestic main user. Last, 
the security model is not fault-resistant as ail the community is compromised as 
1 5 soon as one of its members is compromised. 

When the need for communication over un-trusted networks arose, ! 
the former paradigm didn't suffice. Frontier had to be materialized in a different 
way, that would take in account the possibility to cross non-trusted networks, 
such as the Internet 

20 This gave birth to frontier components such as secured routers and 

firewalls, as well as the notion of private addressing domains. Such components 
enforce correct frontier properties By allowing or denying cross-frontier access. 
Typical architecture is a diode firewall allowing outgoing connections and 
forbidding incoming connections. 

25 The security of the frontier of such community relies mostly on the 

ability of frontier components to detect whether external connections are 
authorized or not. Inside the network, the security relies on the same two factors 
(authorized access and no un-trusted device insertion). 

These communities are not adapted in cases where the network is 

30 very evolutive or when a lot of devices have a nomadic behavior. 

Cross-Network communities really started with nomadic behaviors; 
when a device needs to access the community from an external network 
location. Firewall helped enforcing frontier properties, together with 
authentication servers. 

35 Protocols such as IPv6 (New version of Internet Protocol, as 

specified in "RFC 2460 Internet Protocol, Version 6 (IPv6) Specification. S. 
Deering, R. Hinden. December 1998") and some VPN (Virtual Private Network) 
technologies include mobility and security function that help securing 



communities frontiers. These include HIP and SUCV -(descnbed .n C 
Montenegro and C. Castelluccia. Statistically Unique and Cryptographicatty 
Verifiable (SUCV) identifiers and addresses. In NDSS'02, Feb. 200T). In this 
case however, the complexity is not manageable by a typical domestic user 
5 Moreover, these technologies rely on devices homogeneity (for instance: each 

device has a valid IPv6 address). 

F Stajano proposed a more generic method: the Resurrecting 
Duckling (in "F. Stajano The Resurrecting Duckling- What Next? Lecture Notes 
in Computer Science, 2133:204-211, 2001" and in "F. Stajano and R. 

10 Anderson. The resurrecting duckling: Security issues for ad-hoc wireless 
networks. In 7th International Workshop on Security Protocols, pages 172-194, 
1999."). in this method, however, the main user must validate operations 
whenever a new device is added to the community. Moreover, banishment of a 
device from the community is not an easy operation in the general case. 

15 The main problems when managing and securing community 

frontiers are: 

- Complexity and lack for user friendliness at least in regard to 
domestic user needs. This is mostly true for firewalls (even 
personal firewalls) that remain complex if a fair security level is to 

20 be achieved. 

. Need for heterogeneity, most existing methods fall when not all 

devices are able to communicate by pairs. 

- Lack of robustness when devices are compromised or stolen. 
More precisely, a posteriori revocation (banishment) of a device is 

25 not a simple action in most existing methods. 

SUMMARY O P THE INVENTION 

In order to overcome the above-mentioned problems, the invention 
proposes a system for the secure and distributed management: of a local 
30 network representation within network devices, characterized in that each 

network device (x) contains : 

a provable identity (id*) or means to generate or to obtain a provable 

identity; ' v . 

objects (MT(x). UT(x), DT(x)) memorizing trust relationships between 

35 devices of the community; and 

means for establishing a protocol for trust relationsh.ps 

synchronization. 
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BRIEF DESCRIPTION OF THE DRAWINfifiT ha various features 
and advantages of the present Invention and Its preferred embodiments will now 
be described with reference to the accompanying drawings which are intended 
to illustrate and not to limit the scope of the present invention and in which: 

Fig. 1 illustrates parts of a device implementing the invention. 

Fig. 2 Illustrates an example of a community created according to the 

invention. 

Rg. 3 to 7 illustrate a flowchart of the preferred protocol executed in 
a device z according to the Invention. 

Rg. 8 to 12 are temporal diagrams illustrating different possible 
situations between devices implementing the protocol illustrated in Fig. 3 to 7. 

DETAILED DESCRIPTION OF THE PREFFRPFH 

EMBODIMENTS In the following of the description, the following notatioti will be 
used: 

x » y» z» t, j Variable names for devices. 

id x Provable identity of device x. 

A Community of devices. 

MT(x) Set of devices trusted by x AND trusting x. 

UT(x) Set of devices trusted by x. 

DT(x) Set of devices distrusted by x. 

S x (idy) Proof that device y Is trusted by device x 

The invention is based on the following elements: ;/•':•■ 

1. Each device x of the community has a provable identity id x or is 
able to generate or to receive a provable identity. 

2. Each device x of the community memorizes trust relationships 
between devices of the community in objects MT(x), UT(x) and 
DT(x) respectively containing: 

- MT(x): a set of devices trusted by x AND trusting x. 

- UT(x): a set of devices trusted by x. 

- DT(x): a set of devices distrusted by x. 

3. Each device x of the community furthermore memorizes proofs 
Sj(idx) received from other devices j of the community that x is 
trusted by j. 



4. A protocol for trust relationships synchronization is implemented 
in each device of the community. 

5. The user has the possibility to validate or invalidate trust 
relationships between some devices. 

First, the invention allows distributed and secure enforcement of 

community frontiers. 

Second, the invention minimizes number and complexity of 

interaction between community devices and the main user. 

In the following of the description, the following notation will be used: 

x, y,z, t Variable names for devices. 

id x Provable identity of device x. 

A Community of devices. 

MT(x) Set of devices trusted by x AND trusting x. 

UT(x) Set of devices trusted by x. 

DT(x) Set of devices distrusted by x. 

Sx(idy) Proof that device y is trusted by device x. 

Preferably, objects MT(x), UT(x) and DT(x) are implemented by lists 
containing provable identities idj of the devices j which are part of the set: - 

For example if a device yt trusts a device y and is trusted by y, MT(x) 
will contain id y . MT(x) may also possibly contain some cryptographic material, 
such as keys to allow devices of the community to securely exchange data. In 
the above example, MT(x) may contain a symmetrical key Kxy shared between 
devices x and y. 

In a variant embodiment of the invention, the list of proofs Sj(id x ) may 
be stored in MT(x), each proof S,(idx) being stored with the identity idj of the 
device trusting x and trusted by x. 

In the same way, if a device x trusts a device z but is not necessarily 
trusted by z, then UT(x) will contain id* UT(x) may also contain some 
cryptographic material. 

DT(x) also contains identities idj of devices j which are distrusted by 
x. it may also possibly contain other data such as cryptographic material. 

Basic community operations are: 

• Initialization of a community, denoted init 

The init operation corresponds to the creation of the community, 

generally with a single device. 
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• Insertion of device in a community, denoted insert: 

The insert operation occurs when a new device enters the 
community. This new device should be able to identify the other 
devices of the community.as belonging to the community and the 
5 other members of the community should identify the new device 

as a member of the community. 

• Removal of a device from a community, denoted remove. 

The remove operation shall be used when a device is obsolete. 

This operation will extract the device from the community, but will 
10 not modify trusts relations. In particular, in the case when two 

devices y and z build a trust relationship upon the assumption 

that both devices have trust relationships with device x, the fact 

that device x has been removed has no impact. 

Then the remove operation does not require any information 
16 transmission with other community devices. In particular, this 

operation is valid in the case of a single device community. 

Removing a device x consists in: 
- Destroying x identity (idx) and the ability for x to prove this 
identity. 

20 - Resetting all trust relationships, that is making all sets 

MT(x), UT(x), DT(x) empty. .. . . 

After removal, the device x is unable to . broadcast its identity 
(which has been destroyed). He cannot take any part in 
community devices transmissions as no community device 

25 accepts a transmission with unidentified, device. . : : - . 

• Banishment of a device from a communfty, denoted banish. 
The banish operation shall be used when a device has been lost 
or stolen, or when a device is resale to another user, from another 
community. In this case, the device itself is not available. 

30 Moreover, new trusts relationships that can be build upon trusts 

assumptions with the banished device shall become impossible. 
To banish a device x, the user must select another available 
device y that already has a trust relationship with x (i.e. its identity 
id x belongs either to UT(y) or MT(y». The user asks y to=add {idx} 

35 in its list of distrusted devices DT(y). 

The synchronization operation will insure diffusion of the 
information that device x Is distrusted. Depending on how often 



devices of the community interact, this information may diffuse 
faster over some devices, and slower over all devices. 



Figure 1 illustrates which elements are contained In a device for 
5 implementing the invention. 

A device x typically contains a CPU (Central Processing Unit), a User 
Interface, a memory for storing objects MT(x) UT(x) and DT(x) as well as the list 
of proofs Si(id x ) received from other devices j of the community that x is trusted 
by j The device furthermore contains at least one network interface for 
10 communication with other devices of the community. One device may conta.n 
several network interfaces in order to allow heterogeneous communications in 
the community. 

Figure 2 illustrates an example of a community of: devices 
15 represented by a multi-site domestic network. Devices are for example a 
Personal Computer, a TV set, a storage unit, a PDA, etc. In the situation of 
figure 2. we suppose that all trusts relationships between devices are mutual 
trust. Figure 2 illustrates the moment when device c is about to accept new 
device d in the community, with user validation. 

20 

In the preferred embodiment of the invention; each device contains a 
local agent responsible for its security. The first task of the agent is to manage 
its own provable identity. A provable identity is an identity that has the property 
of being able to be checked by anyone, while being very hard to impersonate. 

25 For instance, the public key of a public/private key pair is a provable identity: an 
agent pretending being identified by its public key can prove It by signing a 
challenge with its private key. SUCV is another mechanism designed for IP 
networks based on the idea of provable identity. 

The local agent is in charge of generating, escrowing and endorsing 

30 its provable identity that will be used to authenticate itself in front of the other 

devices of the community. ' 

The agent is also In charge of locally authenticating the user who 
makes authority on the device to ensure that the security-relevant requests are 
legitimate This local authentication is totally independent from its own provable 
35 identity as well as from the keying process that is made between devices. As a 
consequence, each device can have its own best suited authentication 
procedure (for example by entering a PIN on the device or by biometncs). 



Xfmsait XV 151 P9 



8 

Rnally, the agent is in charge of community management.. It 
possesses and maintains its own list of the community members, which are 
stored in objects MT, UT and DT describes above.. Depending on the 
implementation chosen, these objects can be stored in a single list or in 
different lists. This list or theses lists describe(s) the local knowledge the agent 
has of its community. By securely updating the content of objects MT, UT and 
DT, an agent manages its community. 

Objects MT, UT and DT can be updated by two different means: an 
agent trusts its owner (i.e. the user who owns the device) to decide which 
device can enter in its community. It also trusts the agents it knows as 
belonging to its community (i.e. the agents Jiaving their provable identity in its 
MT or UT), to introduce to him new members of the community; Agents 
belonging to the same community "synchronize" their information with each 
other in a secure way to maintain their respective objects MT, UT and DT up to 
date. 

The agent can be physically implemented in several different way. 

It may be a software downloaded or embedded in the device. It can 
also be a software running in a smart card inserted in the device. The. agent can 
also be implemented by a chip or chip set containing a software. 

We will now describe more precisely the protocol , which is 
implemented in a device z according to the invention. This protocol is described 
in view of figures 3 to 7. - . 

In addition to the notation previously described, the following 
notations are used in these figures: 

a Logical AND » • • 

3?y. P(y) Does it exist a device y, such that condition P holds for y > 
C ^ > Start point "• " ' 

J Sequence instructions 
^ > Timeouted intruction (returns to step 3 unless otherwise > 
specified) "" * "' 

< C^^ > Binary condition 
- 1 1 End point 
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1: Start point used when the main user just acquired a device z with 

no id. 

2: All necessary operations for device z initialization, including: 

software code insertion (unnecessary for chip implementation), creation of 

5 cryptographic key material, creation of the provable identity id z of the device z. 

set up of lists MT(z), UT(z) and DT(z) to empty. 

3: Normal start point for an already initialized device z. 

100: Contains all operations and conditions necessary for device z to 
detect whether another device t belong to the same community A or not Detail 
1 0 for these operations are given in points 1 01 to 1 04. 

101: Device z sends information by any available mean (including 
wired or wireless network protocols). The broadcast information is: fd z and 
MT(z). The next activated point will be 102. 

1 02: This point is automatically activated after the point 101 . Device z 
1 5 waits and listens to all its nelwork interfaces, until it obtains /eft and MT(f) from a 
device t (case 1) or until a timeout expires (case 2). Typical timeout duration in 
the case of domestic network is one or two minutes. If the case 1 occurs then 
the next point activated will be 103 else (case 2) it is 101 . 

103: This point Is activated if the information /eft and MT(f) have been 
20 received from a device f. Device z verifies if it distrusts t or not. If so, the next 
activated point will be 3, else It will be 104. 

104: This point is activated if device z does not distrust device t 
Device z verifies if idt belongs to MT(z) and if device id z belongs to MT(f). If both 
verifications are successful then the next activated point will be 400, else it will 

25 be 200: ' 

200: This point is activated if device z has detected that a device t 
does not (already) belong to the same community. This point contains all 
operations and conditions necessary for device z to detect whether it can enter 
the same community as the device t 's one. Detail for these operations are 

30 given in points 201 to 209. 

201: Device z verifies if it exists a device x such that id x belongs to 
the intersection of the lists MT(z) and MT(r). If so the next activated point will be 

202 else it will be 204. 

202: This point is activated if it exists a device x such that Jd x belongs 
35 to the intersection of the lists MT(z) and MT(f). Device z asks device t for Stfdj. 
The next activated point will be 203. Point 202 is under the control of a timeout 
of typical duration 1 minute. If timeout expires, the next activate point is 3. 
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203: This point is automatically activated after the point 202. Device z 
receives SJid,). from t and verifies it If the verification is successful then the 
next activated point will be 300 else it will be 3. 

204: This point is activated if it does not exist any device x such that 
5 id x belongs to the intersection of the lists MT(z) and MT(f). Device z verifies if it 
exists a device x such that id x belongs to the intersection of the lists LfT(z) and 
MT(f). If so the next activated point will be 205 else it will be 209. 

205: This point is activated if it exists a device x such that ld x belongs 
to the intersection of the lists UT(z) and MT(r). Device z asks device f for S^/oy. 
10 The next activated point will be 206. Point 205 is under the control of a timeout 
of typical duration 1 minute. If timeout expires, the next activate point is 3. 

206: This point is automatically activated after the point 205; Device z 
receives SJid$. from t and verifies ;it. It the verification is successful then the 
next activated point will be 207 else it will be 3. 
15 207: This point is activated if device z has successfully verified 

Sxtfroy. Device z asks device t for UT(f). The next activated point will be 208: 
Point 207 is under the control of a timeout of typical duration 1 minute. If timeout 
expires, the next activate point is 3. 

208: This point is automatically activated after the point 207. Device z 
20 verifies if it exists a device y such that id y belongs to the intersection of the lists 
UT(f) and MT(z). If so the next activated point will be 300 else it will be 3. 

209: This point is activated if it does not exist any device x such that 
id x belongs to the intersection of the lists UT(z) and MT(f). A user validation is 
requested to activate to the next point 300. Point 202 is under the control of a 
25 timeout of typical duration 1 minute, but the main user can configure this 
duration. If timeout expires, the next activate point is 3. 

300: This point is activated when device z has a proof that it can 
accept the device t in its community. This point contains all operations and 
conditions necessary for device z to accept device t in. Its community. Detail for 
30 these operations are given in points 301 to 303. 

301: Lists UT(z) and MT(z) are updated as follows: id t is removed 
from to UT{z) and is inserted in MT(z). The next activated point will be 302, . 

302: This point is automatically activated after the point 30i . Device z 
sends S 2 f/oV to f. The next activated point will be 303. 
35 303: This point is automatically activated after the point 303; Device z 

waits for SM). from t The next activated point will be 400. Point 303 is under 
the control of a timeout of typical duration 1 minute: If timeout expires, the next 
activate point is 3. 
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400: This point is automatically activated after the points 104 
(devices z and t already belong to the same community) or 303, (device z has a 
proof that it can accept the device t in its community). This point contains all 
operations and conditions necessary for device z and device t to share and 
update community information. Detail for these operations are given in points 
401 to 402. 

401: Lists DT(z) and UT(z) are updated as follows: elements of DT(f) 
are added to DT(z). elements of MT(f) are added to UT(z), elements of DT(f) 
are removed from to UT(z). The next activated point will be 402. 

402: This point is automatically activated after the point 401 . Device z 
provides device t with all the community information it possesses. The next 
activated point will be 3. 

Figure 8 illustrates the operations when a device b enters device a's 

community. " 

Figure 9 illustrates the operations when device a meets device d and 

when denters in a's community. 

Figure 10 illustrates the .operations when a device c enters in the 

community of device b. 

Figure 1 1 illustrates the operations when devices c and d establish a 
trusted relationship without any user interaction (using steps 204 to 208 in Fig. 
5). 

Figure 12 illustrates the operations when devices a and c establish a 
trusted relationship without any user interaction (using steps 201 to 203 in Fig. 
5). 

The invention presents the following advantages. 

This invention applies to communities that are highly, dynamic, 
evolutive and heterogeneous. Prior art solutions do not apply in such cases or 
are very demanding to the main user, who is rather a network administrator 
than for instance a domestic user. 

The invention allows secure distribution of any information relevant to 
the community. These include, but are not limited to: configuration information, 
time and time-stamping information, 1 third party protocol, keys, third party mobile 
agents, antiviral signature files... 

The invention applies various technologies, as the agent can be 
inserted in most type of networking devices. 

The invention applies to previously constituted communities, as well 
as it applies to newly constituted communities: the agent can be inserted in 
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older devices if the support enough computation, and memory capacities.- This 
includes, but do not restrict to, older personal computers and older Personal 
Digital Agents. 

The invention allows simple banishment of. a lost, stolen: or 
5 compromised device. Other state of the art solutions don't provide easy means 
for banishing a device that is not accessible anymore. 

The invention insures correct information synchronization and 
diffusion between community devices. This point allows transmission of third 
party cryptographic material for use by other protocols or system. As a non- 
10 limitative list of examples, the invention can transmit 

- Shared secrets for use as WEP or IPSec keys 

- Cryptographic digest of files that will be transmitted over possibly 
insecure protocols (such as FTP).. This files may be software patches, virus 
lists, automated security procedures... ■: 

15 ' * " Cryptographic signature of new versions of software agents (as 

the one used by the invention). 



20 
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CLAIMS 



1. System for the secure and distributed management of a local 
5 network representation within network devices, characterized in that each 
network device (x) contains : 

a provable identity (id x ) or means to generate or to obtain a provable 

identity; 

objects (MT(x), UT(x), DT(x)) memorizing trust relationships between 
1 0 devices of the community; and 

means for establishing a protocol for trust relationships 
synchronization. 
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